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DETAILED ACTION 

1. Claims 1-27 are subject to examination. Claims 1 and 14 have been cancelled. 

Response to Arguments 

2. Applicants arguments with respect to claims 1-27 have been considered but are 
moot in view of the new ground(s) of rejection. 

Claim Rejections ~ 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be patented 
and the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 2-4, 6, 7, 10, 13-17, 19, 20, 23, 26 and 27 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Braddy (US 6, 304, 967 B1 ) in view of Hobbs (US 6, 
523, 022 B1) 

Referring to claims 2 and 13, 

Braddy teaches a computer-implemented system for facilitating communication in a 
distributed network environment (Fig. 4), the system comprising: 

a request broker, implemented as a is implemented as a servlet operating at a 
web server within a hub system (Fig. 4, element 90, col. 11, line 57-67, "The Request 
Broker 90 is implemented as a server side plug-in module interfacing with the web 
server program 64 through the web server plug-in API 65. As such, the Request Broker 
90 operates inside the web server process, sharing both address space and thread of 
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execution with the overall web server program 64. When the web server program 64 
receives a request from a web browser 42, 44, 46, and 48 over the Internet or network 
50, the web server program 64 passes the request to the Request Broker 90 which 
handles further processing of the request.")operable to: 

receive a network application program interface (API) request component from 
one or more clients within the distributed network environment, the one or more clients 
located remote from the hub system (Fig. 4, elements 42, 44.... 48, 50, 52, 72 and 74, 
col. 8, line 19-23, "The Request Broker 90 is a computer program that runs on web 
server computer system 52. The Application Server 92 is a computer program that runs 
on one or more of the secondary application server computer systems 72, 74.", 26-29, 
"Server computer systems 52,72,74 may be of different types in that the present 
invention is computing platform independent.", 34-42, "As such, the client computer 
systems 42, 44, 46, and 48 connected to the first network 50 are running conventional 
web browser programs, and web server computer system 52 is running a conventional 
web server program 64. Web servers typically support "plug-ins" or application 
programming interfaces (API) enabling their basic functionality to be extended by 
software programs, typically called "plug-ins," that use the web server API to perform 
functions within the web server software.", 46-51, "The Request Broker 90 determines 
how to optimally route information requests received by the web server computer 
system 52, enabling requests to execute locally on the web server computer system 52 
or remotely on one or more secondary application server computer systems 72, 74."), 
the network API request component comprising a description of a system API method to 
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be called and one or more parameters to be used in executing the system API method, 
the parameters having one of a plurality of acceptable native formats; 

determine the native format of the parameters; communicate the parameters in 
the native format to a selected one of a plurality of translators for translation of the 
parameters from the native format to an internal format, each translator being 
associated with a different native format; and communicate the parameters in the 
internal format to an application server to enable execution of the system API method 
according to the parameters (Fig. 7, col. 10, line 28-37, "Category "File Types" 82 in the 
Request Broker configuration file contains information identifying the different request 
file extensions that the Request Broker 90 is configured to handle. For example, the 
Request Broker 90 may be configured to handle requests that involve the execution of 
files with different file extensions, such as ".exe" for executable program files, ".pi" for 
Perl program files, ".cgi" for CGI program files, ".bat" for batch program files, or ".asp" 
for Active Server Page files.", col. 12, line 21-31, "As shown in FIG. 8b, the 
determination of whether the Request Broker 90 will handle the incoming request in 
step 208 has a number of steps. The Adapter 100 examines the incoming request and 
examines the Request Broker's configuration information to determine whether the 
Request Broker 90 is configured to handle the processing of the request. In step 216, 
the Adapter 100 examines the Request Broker configuration file to determine whether 
the Request Broker 90 is enabled to handle requests from the web server program 64.", 
col. 12, line 54-56, "If the request's file extension is supported by the Request Broker 
90, then the Adapter 100 continues to step 222.", col. 12, line 65-col. 13, line 13, 
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"Otherwise, the Adapter 100 continues on to step 212, where the request, and its 
parameters, are converted from the web server API request data format into new 
request "package" information format for continued processing in the Request Broker 
90. This new request "package" data format is merely a data structure format used by 
the preferred embodiment of the present invention to facilitate processing of the request 
throughout the program modules of the preferred embodiment. The re-formatting of the 
request allows for more efficient and transparent processing of the request because 
different types of requests may be received from the web server program 64. 
Reformatting the incoming request to a consistent format allows different types of 
requests to be handled in the same manner within the preferred embodiment", col. 17, 
line 52-60, Note: Broker's file configurations are translators); and 

the application server system, operable to receive the parameters from the 
request broker in the internal format, generate a return value reflecting execution of the 
system API method according to the parameters, and communicate the return value to 
the request broker in the internal format (col. 17, line 52-60, Fig. 14, col. 23, line 12-15, 
34-44) 

the request broker further operable to receive the return value from the 
application server system in the internal format, communicate the return value in the 
internal format to the selected translator for translation of the return value from the 
internal format to the native format, generate a network API reply component that 
comprises the description of the system API method that was called and the return 
value in the native format, and communicate the network API reply component to the 
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one or more clients, (col. 13, line 12-18, "As will be shown in a later step, after the 
request has been processed, the request "reply" format will be converted back to the 
request's original type of data format for transmission to the web browser 42, 44, 46, 
and 48 originating the request. This allows the preferred embodiment of the present 
invention to be easily adapted or modified to handle new or different data request 
formats.", col. 13, line 22-30, "Referring to FIG. 8c, after the request has been 
processed by the Broker Manager 102, in step 224, the results of the request (the 
request reply "package") are sent from the Broker Manager 102 and received by the 
Adapter 100. In step 226, the request reply "package" data format is converted back 
into the web server's original API request format, stored in a request reply buffer (not 
shown), and transmitted back to the web browser client 42,44,46,48 that originated the 
request."); 

Interestingly enough to a one having ordinary skill in the art, Braddy provides 
firewall and security between web server and application servers as indicated in Fig. 17, 
col. 26, line 21-34 and col. 24, line 59-65, concurrently Braddy fails to teach wherein a 
request broker operating at a Secure Hypertext Transport Protocol (HTTPS) web 
server; and the network API request and network API reply components comprise Multi- 
purpose Internet Mail Extension (MIME) containers communicated over the Internet in 
HTTPS messages and a system firewall having a plurality of ports, the system 
maintaining at least one port of the system firewall open for communication with the 
client, the client initiating a connection to the system through the at least one open port 
of the system firewall to communicate the network API request component to the 
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request broker, independent of any port of a client firewall being open for 
communication with the system. 

Hobbs teaches in col. 21, Iine66 through col. 22, line 5," The Java Servlet API 
also permits the servers and client to establish end to end (browser to Application 
Server to Database Server and back) channel security through Secure Sockets Layer 
(SSL) or Secure HyperText Transport Protocol (S-HTTP). It would also encrypt all data 
passing from the client to the Application Server and from the Application Server to the 
Database Server. "(the request broker is implemented as a servlet operating at a Secure 
Hypertext Transport Protocol (HTTPS) web server; and the network API request and 
network API reply components comprise Multi-purpose Internet Mail Extension (MIME) 
containers communicated over the Internet in HTTPS messages and further comprising 
a system firewall having a plurality of ports, the system maintaining at least one port of 
the system firewall open for communication with the client, the client initiating a 
connection to the system through the at least one open port of the system firewall to 
communicate the network API request component to the request broker, independent of 
any port of a client firewall being open for communication with the system., 
Communicating MIME containers is well known in art wherein MIME is part of HTTP, 
and both Web browsers and HTTP servers., It is also well known in art to have port 443 
as a default listening port for HTTPS). 

Therefore, it would have been obvious to one having ordinary skill in the art, 
having the teachings of Braddy and Hobbs in front of him at the time of invention was 
made, to incorporate the teachings of Hobbs into Braddy's web server such that the 
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access to servers may be restricted to particular clients providing not only firewall 
between it's web server and application servers but also to the web server from the 
network 50 of Fig. 4. 

This would have been obvious also since Hobb's teaching itself prophesizes "The 
Java Servlet API also permits the servers and client to establish end to end (browser to 
Application Server to Database Server and back) channel security through Secure 
Sockets Layer (SSL) or Secure HyperText Transport Protocol (S-HTTP). It would also 
encrypt all data passing from the client to the Application Server and from the 
Application Server to the Database Server." This basically solves the problem 
thoroughly that is raised by Braddy in col. 5, line 14-24. 
Referring to claim 3 and 4, 

Braddy teaches the system of claim 1 , wherein the one or more clients comprises 
at least one of a remote application, a remote spoke, and a remote hub system, and the 
system of claim 1, wherein the request broker is a component of an electronic 
marketplace, the one or more clients are remote from the electronic marketplace, and 
the one or more clients comprise at least one of a remote enterprise application, a 
remote spoke, and a remote electronic marketplace. (Fig. 1, col. 5, line 14-24, col. 1, 
line 34-50, col. 3, line 15-36) 
Referring to claim 6, 

Braddy teaches the system of claim 1, wherein the system API method is called 
using a synchronous method invocation semantic. (Abstract). 
Referring to claim 7, 
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Braddy teaches the system of claim 1, wherein the application server system 
(Fig. 14) comprises an application server (Fig. 14, element 92) and a plurality of 
associated adapters , the request broker communicating the parameters in the internal 
format to a selected one of the plurality of adapters to enable execution of the system 
API method according to the parameters, the selected adapter being operable to: 
receive the parameters from the request broker in the internal format; communicate the 
parameters to the application server in the internal format for execution of the system 
API method according to the parameters; receive the return value from the application 
server reflecting execution of the system API method according to the parameters; and 
communicate the return value to the request broker in the internal format, (col. 22, line 9 
-col. 23, line 21, Note: Filters (Fig. 14, elements 412) are adapters.) 
Referring to claim 10, 

Braddy teaches the system of claim 1, wherein the network API reply comprises 
a format field describing how to interpret the return value and corresponding to the 
selected translator (col. 13, line 22-30, line 12-18, col. 17, line 52-60, Fig. 14, col. 23, 
line 12-15, 34-44). 
Referring to claims 15 and 26, 

Claims 15 and 26 are claims to computer implemented method that is carried out by the 
system of claims 2 and 13. Therefore, claims 15 and 26 are rejected for the reasons set 
forth for claims 2 and 1 3. 
Referring to claims 16 and 17, 
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Claims 16 and 17 are claims to computer implemented method that is carried out by the 
system of claims 3 and 4. Therefore, claims 16 and 17 are rejected for the reasons set 
forth for claims 3 and 4. 
Referring to claim 19, 

Claim 19 is a claim to a computer implemented method that is carried out by the system 
of claim 6. Therefore, claim 19 is rejected for the reasons set forth for claim 6. 
Referring to claim 20, 

Claim 20 is a claim to a computer implemented method that is carried out by the system 
of claim 7. Therefore, claim 20 is rejected for the reasons set forth for claim 7. 
Referring to claim 23, 

Claim 23 is a claim to a computer implemented method that is carried out by the system 
of claim 10. Therefore, claim 23 is rejected for the reasons set forth for claim 10. 
Referring to claim 27, 

Claim 27 is a claim to a system identified in claim 1. Claim 1 identifies the means 
associated with the system limitations of claim 27. Therefore, claim 27 is rejected for 
the reasons set forth for claim 1 . 

5. Claims 5 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Braddy (US 6, 304, 967 B1) in view of Hobbs (US 6, 523, 022 B1) as applied to claims 
2 and 13 above, and further in view of Cooper et al. (hereinafter Cooper) (US 
2003/0121000 A1). 
Referring to claim 5, 
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Keeping in mind the teachings of Braddy and Hobbs as stated above, both 
references fail to explicitly teach wherein: the plurality of acceptable native formats 
comprises Extensible Markup Language (XML), Electronic Data Interchange (EDI), and 
serialized object formats; and the internal format comprises serialized object format, the 
parameters being converted into serialized object classes by the selected translator. 

Cooper teaches these elements in paragraphs [0043], [0045], [0071]-[0073]. 

Therefore, it would have been obvious to one having ordinary skill in the art, 
having the teachings of Braddy, Hobbs and Cooper in front of him at the time of 
invention was made, to incorporate the teachings of Cooper into Braddy's request 
broker along with Hobb's teachings such that it would be useful to have a method for 
adapting well-known APIs in some manner for use as a Web-based page description 
language. It would be particularly advantageous for the method to provide the ability to 
produce documents that conform with evolving markup language processing standards 
as taught by Cooper. 
Referring to claim 18, 

Claim 18 is a claim to a computer implemented method that is carried out by the system 
of claim 5. Therefore, claim 1 8 is rejected for the reasons set forth for claim 5. 

6. Claims 8 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Braddy (US 6, 304, 967 B1) in view of Hobbs (US 6, 523, 022 B1) as applied to claims 
2 and 13 above, and further in view of Gervais et al. (hereinafter Gervais) (US 6, 381, 
579). 
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Referring to claim 8, 

Keeping in mind the teachings of Braddy and Hobbs as sated above, both 
references fail to explicitly teach the system of claim 13, wherein the application server 
system supports one or more applications comprising at least a collaborative planning 
application operable to provide planning data for one or more clients within a supply 
chain. 

Gervais does "Provide an electronic-business-to-electronic-business portal that 
organizes the access to extended business applications. A method allows end users to 
access a server using standard Web browsers, and then view their own customized 
menu of applications. Enhanced security and administrative tools allow this portal to be 
shared throughout enterprises and across supply chains, providing secure access to 
collaborative applications by business partners and suppliers. (Abstract). Thereby the 
reference teaches the application server system supports one or more applications 
comprising at least a collaborative planning application operable to provide planning 
data for one or more clients within a supply chain. 

Therefore, it would have been obvious to one having ordinary skill in the art at 
the time of invention was made to incorporate the teachings of the reference Gervais 
into Braddy's request broker along with the teachings of Hobbs such that it provides a 
common infrastructure for application administration, security management, and 
directory use, which can help reduce information technology (IT) costs and speed 
solution deployment as taught by Gervais. (Abstract). 
Referring to claim 21, 
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Claim 21 is a claim to a computer implemented method that is carried out by the system 

of claim 8. Therefore, claim 21 is rejected for the reasons set forth for claim 8. 

7. Claims 9, 11, 12, 22, 24 and 25 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Braddy (US 6, 304, 967 B1) (US 5, 329, 619) in view of Hobbs (US 

6, 523, 022 B1) as applied to claims 2 and 13 above, and further in view of in view of 

Lam et al. (hereinafter Lam) (US 5, 926, 636). 

Referring to claims 9, 11 and 12, 

Keeping in mind the teachings of the references Braddy and Hobbs as stated 
above, both references fail to teach wherein the network API request component and 
network API reply component each comprise a version identifier indicating the version 
of the network API request component and network API reply component being used, 
and wherein the network API reply comprises a deprecation notice indicating to the one 
or more clients that the system API method that was called should not be further used, 
and wherein the request broker is further operable to generate a network API exception 
component based on an exception occurring in connection with execution of a second 
system API method called based on a network API request component received from a 
second client, the network API exception component comprising a description of the 
second system API method, a description of the exception, and a deprecation notice 
indicating to the second client that the second system API method should not be further 
used. 

Lam teaches "the network API request component and network API reply 
component each comprise a version identifier indicating the version of the network API 
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request component and network API reply component being used. (Abstract). The 
reference also teaches wherein the network API reply comprises a deprecation notice 
indicating to the client that the system API method that was called should not be further 
used, and wherein the request broker is further operable to generate a network API 
exception component based on an exception occurring in connection with execution of a 
second system API method called based on a network API request component received 
from a second client, the network API exception component comprising a description of 
the second system API method, a description of the exception, and a deprecation notice 
indicating to the second client that the second system API method should not be further 
used. (Abstract, col. 8, lines 4-17). 

Therefore, it would have been obvious to one having ordinary skill in the art at 
the time of invention was made to incorporate the teachings of the reference Lam into 
Braddy's request broker long with the teachings of Hobbs such that the server 
component management application programming interface reads a field in the 
message to determine whether an addressing format of the client computer is 
compatible with an addressing format of the server computer. If the addressing formats 
are not compatible, the server component management application programming 
interface converts the message to an addressing format compatible with the server 
computer. 

Referring to claims 22, 24 and 25, 
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Claims 22, 24 and 25 are claims to computer implemented method that is carried out by 
the system of claims 9, 1 1 and 12. Therefore, claims 22, 24 and 25 are rejected for the 
reasons set forth for claims 9, 1 1 and 12. 

Conclusion 

Examiner's note: Examiner has cited particular columns and line numbers in the 
references as applied to the claims above for the convenience of the applicant. 
Although the specified citations are representative of the teachings of the art and are 
applied to the specific limitations within the individual claim, other passages and figures 
may apply as well. It is respectfully requested from the applicant in preparing responses, 
to fully consider the references in entirety as potentially teaching all or part of the 
claimed invention, as well as the context of the passage as taught by the prior art or 
disclosed by the Examiner. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ashok B. Patel whose telephone number is (571) 272- 
3972. The examiner can normally be reached on 8:00am-5:00pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John A Follansbee can be reached on (571) 272-3964. The fax phone 
number for the organization where this application or proceeding is assigned is 703- 
872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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